System and method for verifying and restoring the consistency of inode to pathname mappings in a filesystem

ABSTRACT

A system and method verifies and restores the consistency of inode to pathname mappings. In a first embodiment, an off-line verification procedure is modified to verify and correct the primary name inode to pathname mapping information within inodes of a file system. In a second embodiment, an on-line file system verification process is modified to verify inode to pathname mapping information upon the loading of each inode within the file system.

RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.11/233,441 filed on Sep. 22, 2005, by Edward R. Zayas et al., entitledSYSTEM AND METHOD FOR VERIFYING AND RESTORING THE CONSISTENCY OF INODETO PATHNAME MAPPINGS IN A FILESYSTEM, now issued as U.S. Pat. No.7,707,193 on Apr. 27, 2010, the teachings of which are expresslyincorporated herein by reference, which is related to the following:

U.S. patent application Ser. No. 11/156,679, entitled SYSTEM AND METHODFOR MAINTAINING MAPPINGS FROM DATA CONTAINERS TO THEIR PARENTDIRECTORIES, by Edward Zayas, et al., now issued as U.S. Pat. No.7,739,318 on Jun. 5, 2010, the teachings of which are expresslyincorporated herein by reference; and

U.S. Pat. No. 6,895,413, entitled SYSTEM AND METHOD FOR PERFORMING ANON-LINE CHECK OF A FILE SYSTEM, by John K. Edwards, the teachings ofwhich are expressly incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to file systems and, more specifically, toverifying and restoring the consistency of mappings from data containersto their corresponding parent directories in a file system.

BACKGROUND OF THE INVENTION

A storage system typically comprises one or more storage devices intowhich information may be entered, and from which information may beobtained, as desired. The storage system includes a storage operatingsystem that functionally organizes the system by, inter alia, invokingstorage operations in support of a storage service implemented by thesystem. The storage system may be implemented in accordance with avariety of storage architectures including, but not limited to, anetwork-attached storage (NAS) environment, a storage area network (SAN)and a disk assembly directly attached to a client or host computer. Thestorage devices are typically disk drives organized as a disk array,wherein the term “disk” commonly describes a self-contained rotatingmagnetic media storage device. The term disk in this context issynonymous with hard disk drive (HDD) or direct access storage device(DASD).

Storage of information on the disk array is preferably implemented asone or more storage “volumes” of physical disks, defining an overalllogical arrangement of disk space. The disks within a volume aretypically organized as one or more groups, wherein each group may beoperated as a Redundant Array of Independent (or Inexpensive) Disks(RAID). Most RAID implementations enhance the reliability/integrity ofdata storage through the redundant writing of data “stripes” across agiven number of physical disks in the RAID group, and the appropriatestoring of redundant information (parity) with respect to the stripeddata. The physical disks of each RAID group may include disks configuredto store striped data (i.e., data disks) and disks configured to storeparity for the data (i.e., parity disks). The parity may thereafter beretrieved to enable recovery of data lost when a disk fails. The term“RAID” and its various implementations are well-known and disclosed in ACase for Redundant Arrays of Inexpensive Disks (RAID), by D. A.Patterson, G. A. Gibson and R. H. Katz, Proceedings of the InternationalConference on Management of Data (SIGMOD), June 1988.

The storage operating system of the storage system may implement ahigh-level module, such as a file system, to logically organize theinformation stored on the disks as a hierarchical structure ofdirectories, files and blocks. For example, each “on-disk” file may beimplemented as set of data structures, i.e., disk blocks, configured tostore information, such as the actual data for the file. These datablocks are organized within a volume block number (vbn) space that ismaintained by the file system. The file system organizes the data blockswithin the vbn space as a “logical volume”; each logical volume may be,although is not necessarily, associated with its own file system. Thefile system typically consists of a contiguous range of vbns from zeroto n, for a file system of size n+1 blocks.

A known type of file system is a write-anywhere file system that doesnot over-write data on disks. If a data block is retrieved (read) fromdisk into a memory of the storage system and “dirtied” (i.e., updated ormodified) with new data, the data block is thereafter stored (written)to a new location on disk to optimize write performance. Awrite-anywhere file system may initially assume an optimal layout suchthat the data is substantially contiguously arranged on disks. Theoptimal disk layout results in efficient access operations, particularlyfor sequential read operations, directed to the disks. An example of awrite-anywhere file system that is configured to operate on a storagesystem is the Write Anywhere File Layout (WAFL®) file system availablefrom Network Appliance, Inc., of Sunnyvale, Calif.

The storage system may be configured to operate according to aclient/server model of information delivery to thereby allow manyclients to access the directories, files and blocks stored on thesystem. In this model, the client may comprise an application, such as adatabase application, executing on a computer that “connects” to thestorage system over a computer network, such as a point-to-point link,shared local area network, wide area network or virtual private networkimplemented over a public network, such as the Internet. Each client mayrequest the services of the file system by issuing file system protocolmessages (in the form of packets) to the storage system over thenetwork. By supporting a plurality of file system protocols, such as theconventional Common Internet File System (CIFS) and the Network FileSystem (NFS) protocols, the utility of the storage system is enhanced.

Each data container, such as a file, directory, etc., within a filesystem is typically associated with an inode that serves as the root ofa buffer tree of the data container. The buffer tree is an internalrepresentation of blocks for the data container stored in the memory ofthe storage system and maintained by the file system. The inode is adata structure used to store information, such as metadata, about thedata container, whereas the data blocks are structures used to store theactual data for the container. The inode typically contains a set ofpointers to other blocks within the file system. For data containers,such as files, that are sufficiently small, the inode may directly pointto blocks storing the data of the file. However, for larger files, theinode points to one or more levels of indirect blocks, which, in turn,may point to additional levels of indirect blocks and/or the blockscontaining the data.

Certain events occurring within the storage system and/or a storageoperating system executing thereon may result in a message beingdisplayed to an administrator. For example, the storage system maydetect that one or more data containers have become corrupted. Apathname provides a way for the administrator to refer to a datacontainer served by the storage system. To that end, each pathnametypically represents one data container within the hierarchicalstructure of the file system. However, the storage system typicallyreports the identity of the data container to the administrator by usingits associated inode number. The inode number is used internally withinthe file system to identify the inode associated with the data containerand, unfortunately, is not easily understood by humans. It is thereforedesirous for the administrator to know the pathname of the datacontainer to which the message relates so that appropriate action may betaken. One technique for generating inode to pathname information (I2P)is described in the above incorporated U.S. Pat. No. 7,739,318, entitledSYSTEM AND METHOD FOR GENERATING AND MAINTAINING INODE TO PATHNAMEMAPPING INFORMATION, by Edward Zayas, et al. In such an environment, aprimary name data structure is included within each inode. The primaryname data structure contains information identifying a specificdirectory entry associated with a primary name of the data container.Illustratively, additional names for a data container, e.g., hard links,may be stored in an alternate name file in a metadata directory withinthe file system.

In systems that contain I2P mapping information, it is possible for thepersistently stored I2P information to become corrupted. For example,memory may become corrupted due to hardware failures. Such memorycorruption may be stored as I2P information on disk, thereby resultingin inconsistent I2P information. Other causes of errors may be filesystem errors and/or data corruption due to errors in applicationsattempting to retrieve I2P mapping information.

A “brute force” technique for correcting the consistency of I2Pinformation is to delete all of the I2P information and to recomputethat information for an entire volume associated with a storage system.A noted disadvantage of such a brute force technique is that in a systemwith tens or hundreds of millions of data containers, the time requiredto reconstruct all of the I2P mapping information may be significant.Additionally, while the I2P information is being reconstructed, anycommands that attempt to retrieve I2P information will fail.

SUMMARY OF THE INVENTION

The present invention overcomes the disadvantages of the prior art byproviding a system and method for verifying and restoring theconsistency of inode to pathname mappings from a data container to itsparent directory within a file system of a storage system. In a firstembodiment, an off-line volume verification tool is modified to, interalia, verify the consistency of I2P information within the file system.Any primary name data structures that are identified as inconsistent arerepaired so that each data structure contains the appropriateinformation representative of the primary name for the data container,such as a file. An alternate name file is verified and ifinconsistencies are noted therein, the alternate name file is deletedand an I2P name mapping scanner is invoked to reconstruct the alternatename file.

In a second embodiment of the invention, an on-line file systemverification tool verifies the consistency of I2P information within thefile system. The on-line verification tool modifies function calls(LoadInode( )) and buffer trees (LoadBuffer( )) within a storageoperating system that load inodes and contents of buffer trees. Beforean inode or buffer tree is returned to a process that called the loadingfunction the verification tool performs a check of the inode and relatedbuffer trees. Illustratively, this check includes, inter alia, verifyingand repairing the consistency of the I2P information associated with theinode. In this second illustrative embodiment, a background process isinitiated that sequentially loads inodes to ensure that all of theinodes of the file system are checked, even if another process orapplication does not request a particular inode.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and further advantages of the invention may be betterunderstood by referring to the following description in conjunction withthe accompanying drawings in which like reference numerals indicateidentical or functionally similar elements:

FIG. 1 is a schematic block diagram of an exemplary storage systemenvironment in accordance with an embodiment of the present invention;

FIG. 2 is a schematic block diagram of a storage operating system inaccordance with an embodiment of the present invention;

FIG. 3 is a schematic block diagram of an exemplary volume buffer treein accordance with an embodiment of the present invention;

FIG. 4 is a schematic block diagram of an inode in accordance with anembodiment of the present invention;

FIG. 5 is a schematic block diagram of an exemplary directory buffertree in accordance with an embodiment of the present invention;

FIG. 6 is a flowchart detailing the steps of a procedure for creating anew name and associated inode to pathname mapping information inaccordance with an embodiment of the present invention;

FIG. 7 is a flowchart detailing the steps of a procedure for retrievinginode to pathname mapping information in accordance with an embodimentof the present invention;

FIG. 8 is a flowchart detailing the steps of a procedure for deleting aname and associated inode to pathname mapping information in accordancewith an embodiment of the present invention;

FIG. 9 is a flowchart detailing the steps of a procedure for performingan off-line verification of inode to pathname mapping information inaccordance with an embodiment of the present invention;

FIG. 10 is a flowchart detailing the steps of a procedure for performingan on-line verification of inode to pathname mapping information inaccordance with an embodiment of the present invention;

FIG. 11 is a flowchart detailing the steps of a procedure for mounting avolume in accordance with an embodiment of the present invention;

FIG. 12 is a flowchart detailing the steps of a procedure for loading aninode while performing an on-line verification of inode to pathnamemapping information in accordance with an embodiment of the presentinvention;

FIG. 13 is a flowchart detailing the steps of a procedure for checkingan inode in accordance with an embodiment of the present invention;

FIG. 14 is a flowchart detailing the steps of a procedure for verifyinga directory in accordance with an embodiment of the present invention;and

FIG. 15 is a flowchart detailing the steps of a procedure executed by ascanner to ensure that all inodes are verified in an on-line check of afile system in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION OF AN ILLUSTRATIVE EMBODIMENT A. Storage SystemEnvironment

FIG. 1 is a schematic block diagram of an environment 100 including astorage system 120 that may be advantageously used with the presentinvention. The storage system is a computer that provides storageservice relating to the organization of information on storage devices,such as disks 130 of a disk array 160. The storage system 120 comprisesa processor 122, a memory 124, a network adapter 126 and a storageadapter 128 interconnected by a system bus 125. The storage system 120also includes a storage operating system 200 that preferably implementsa high-level module, such as a file system, to logically organize theinformation as a hierarchical structure of directories, files andvirtual disks (“vdisks”) on the disks.

In the illustrative embodiment, the memory 124 comprises storagelocations that are addressable by the processor and adapters for storingsoftware program code. A portion of the memory may be further organizedas a “buffer cache” 170 for storing certain data structures associatedwith the present invention. The processor and adapters may, in turn,comprise processing elements and/or logic circuitry configured toexecute the software code and manipulate the data structures. Storageoperating system 200, portions of which are typically resident in memoryand executed by the processing elements, functionally organizes thesystem 120 by, inter alia, invoking storage operations executed by thestorage system. It will be apparent to those skilled in the art thatother processing and memory means, including various computer-readablemedia, may be used for storing and executing program instructionspertaining to the inventive technique described herein.

The network adapter 126 comprises the mechanical, electrical andsignaling circuitry needed to connect the storage system 120 to a client110 over a computer network 140, which may comprise a point-to-pointconnection or a shared medium, such as a local area network.Illustratively, the computer network 140 may be embodied as an Ethernetnetwork or a Fibre Channel (FC) network. The client 110 may communicatewith the storage system over network 140 by exchanging discrete framesor packets of data 150 according to pre-defined protocols, such as theTransmission Control Protocol/Internet Protocol (TCP/IP).

The client 110 may be a general-purpose computer configured to executeapplications 112. Moreover, the client 110 may interact with the storagesystem 120 in accordance with a client/server model of informationdelivery. That is, the client may request the services of the storagesystem, and the system may return the results of the services requestedby the client, by exchanging packets 150 over the network 140. Theclients may issue packets including file-based access protocols, such asthe Common Internet File System (CIFS) protocol or Network File System(NFS) protocol, over TCP/IP when accessing information in the form offiles and directories. Alternatively, the client may issue packetsincluding block-based access protocols, such as the Small ComputerSystems Interface (SCSI) protocol encapsulated over TCP (iSCSI) and SCSIencapsulated over Fibre Channel (FCP), when accessing information in theform of blocks.

The storage adapter 128 cooperates with the storage operating system 200executing on the system 120 to access information requested by a user(or client). The information may be stored on any type of attached arrayof writable storage device media such as video tape, optical, DVD,magnetic tape, bubble memory, electronic random access memory,micro-electro mechanical and any other similar media adapted to storeinformation, including data and parity information. However, asillustratively described herein, the information is preferably stored onthe disks 130, such as HDD and/or DASD, of array 160. The storageadapter includes input/output (I/O) interface circuitry that couples tothe disks over an I/O interconnect arrangement, such as a conventionalhigh-performance, FC serial link topology.

Storage of information on array 160 is preferably implemented as one ormore storage “volumes” that comprise a collection of physical storagedisks 130 cooperating to define an overall logical arrangement of volumeblock number (vbn) space on the volume(s). Alternately, the informationmay be implemented as one or more aggregates comprising of one or moreflexible (virtual) volumes. Aggregates and flexible volumes aredescribed in detail in U.S. Pat. No. 7,409,494, entitled EXTENSION OFWRITE ANYWHERE FILE SYSTEM LAYOUT, by John K. Edwards, et al.

The disks within the file system are typically organized as one or moregroups, wherein each group may be operated as a Redundant Array ofIndependent (or Inexpensive) Disks (RAID). Most RAID implementations,such as a RAID-4 level implementation, enhance the reliability/integrityof data storage through the redundant writing of data “stripes” across agiven number of physical disks in the RAID group, and the appropriatestoring of parity information with respect to the striped data. Anillustrative example of a RAID implementation is a RAID-4 levelimplementation, although it should be understood that other types andlevels of RAID implementations may be used in accordance with theinventive principles described herein.

B. Storage Operating System

To facilitate access to the disks 130, the storage operating system 200illustratively implements a write-anywhere file system that cooperateswith virtualization modules to “virtualize” the storage space providedby disks 130. The file system logically organizes the information as ahierarchical structure of named directories and files on the disks. Each“on-disk” file may be implemented as set of disk blocks configured tostore information, such as data, whereas the directory may beimplemented as a specially formatted file in which names and links toother files and directories are stored. The virtualization modules allowthe file system to further logically organize information as ahierarchical structure of blocks on the disks that are exported as namedlogical unit numbers (luns).

In the illustrative embodiment, the storage operating system ispreferably the NetApp® Data ONTAP™ operating system available fromNetwork Appliance, Inc., Sunnyvale, Calif. that implements a WriteAnywhere File Layout (WAFL®) file system. However, it is expresslycontemplated that any appropriate storage operating system may beenhanced for use in accordance with the inventive principles describedherein. As such, where the term “ONTAP” is employed, it should be takenbroadly to refer to any storage operating system that is otherwiseadaptable to the teachings of this invention.

FIG. 2 is a schematic block diagram of the storage operating system 200that may be advantageously used with the present invention. The storageoperating system comprises a series of software layers organized to forman integrated network protocol stack or, more generally, amulti-protocol engine that provides data paths for clients to accessinformation stored on the storage system using block and file accessprotocols. The protocol stack includes a media access layer 210 ofnetwork drivers (e.g., gigabit Ethernet drivers) that interfaces tonetwork protocol layers, such as the IP layer 212 and its supportingtransport mechanisms, the TCP layer 214 and the User Datagram Protocol(UDP) layer 216. A file system protocol layer provides multi-protocolfile access and, to that end, includes support for, inter alia, theDirect Access File System (DAFS) protocol 218, the NFS protocol 220, theCIFS protocol 222 and the Hypertext Transfer Protocol (HTTP) protocol224. A VI layer 226 implements the VI architecture to provide directaccess transport (DAT) capabilities, such as RDMA, as required by theDAFS protocol 218.

An iSCSI driver layer 228 provides block protocol access over the TCP/IPnetwork protocol layers, while a FC driver layer 230 receives andtransmits block access requests and responses to and from the storagesystem. The FC and iSCSI drivers provide FC-specific and iSCSI-specificaccess control to the blocks and, thus, manage exports of luns to eitheriSCSI or FCP or, alternatively, to both iSCSI and FCP when accessing theblocks on the storage system. In addition, the storage operating systemincludes a storage module embodied as a RAID system 240 that manages thestorage and retrieval of information to and from the volumes/disks inaccordance with I/O operations, and a disk driver system 250 thatimplements a disk access protocol such as, e.g., the SCSI protocol.

Bridging the disk software layers with the integrated network protocolstack layers is a virtualization system that is implemented by a filesystem 280 interacting with virtualization modules illustrativelyembodied as, e.g., vdisk module 290 and SCSI target module 270. Thevdisk module 290 cooperates with the file system 280 to enable access byadministrative interfaces, such as a user interface (UI) 275, inresponse to a user (system administrator) issuing commands to thestorage system. The SCSI target module 270 is disposed between the FCand iSCSI drivers 228, 230 and the file system 280 to provide atranslation layer of the virtualization system between the block (lun)space and the file system space, where luns are represented as blocks.The UI 275 is disposed over the storage operating system in a mannerthat enables administrative or user access to the various layers andsystems.

The file system is illustratively a message-based system that provideslogical volume management capabilities for use in access to theinformation stored on the storage devices, such as disks. That is, inaddition to providing file system semantics, the file system 280provides functions normally associated with a volume manager. Thesefunctions include (i) aggregation of the disks, (ii) aggregation ofstorage bandwidth of the disks, and (iii) reliability guarantees, suchas mirroring and/or parity (RAID). The file system 280 illustrativelyimplements the WAFL file system (hereinafter generally the“write-anywhere file system”) having an on-disk format representationthat is block-based using, e.g., 4 kilobyte (KB) blocks and using indexnodes (“inodes”) to identify files and file attributes (such as creationtime, access permissions, size and block location). The file system usesfiles to store metadata describing the layout of its file system; thesemetadata files include, among others, an inode file. A file handle,i.e., an identifier that includes an inode number, is used to retrievean inode from disk.

Broadly stated, all inodes of the write-anywhere file system areorganized into the inode file. Volume information (volinfo) and filesystem information (fsinfo) blocks specify the layout of information inthe file system, the latter block including an inode of a file thatincludes all other inodes of the file system (the inode file). Eachlogical volume (file system) has an fsinfo block that is preferablystored at a fixed location within, e.g., a RAID group. The inode of thefsinfo block may directly reference (point to) blocks of the inode fileor may reference indirect blocks of the inode file that, in turn,reference direct blocks of the inode file. Within each direct block ofthe inode file are embedded inodes, each of which may reference indirectblocks that, in turn, reference data blocks of a file.

Operationally, a request from the client 110 is forwarded as a packet150 over the computer network 140 and onto the storage system 120 whereit is received at the network adapter 126. A network driver (of layer210 or layer 230) processes the packet and, if appropriate, passes it onto a network protocol and file access layer for additional processingprior to forwarding to the write-anywhere file system 280. Here, thefile system generates operations to load (retrieve) the requested datafrom disk 130 if it is not resident “in-core”, i.e., in the buffer cache170. If the information is not in the cache, the file system 280 indexesinto the inode file using the inode number to access an appropriateentry and retrieve a logical volume block number (vbn). The file systemthen passes a message structure including the logical vbn to the RAIDsystem 240; the logical vbn is mapped to a disk identifier and diskblock number (disk,dbn) and sent to an appropriate driver (e.g., SCSI)of the disk driver system 250. The disk driver accesses the dbn from thespecified disk 130 and loads the requested data block(s) in buffer cache170 for processing by the storage system. Upon completion of therequest, the storage system (and operating system) returns a reply tothe client 110 over the network 140.

Included in the storage operating system 200 is a set of inode topathname (I2P) functions 284. The I2P functions 284, in conjunction withthe file system 280, illustratively implement I2P mapping functionalityin accordance with the present invention. One exemplary technique forI2P mappings is described in the above-incorporated U.S. Pat. No.7,739,318. The I2P functions 284 may include various scanners, describedfurther below, that operate to install/remove I2P mappings in accordancewith embodiments of the present invention. Additionally, the I2Pfunctions 284 may include an application program interface (API) that isexposed to enable other processes executing within the storage operatingsystem to perform I2P mappings. The API may also be accessible viaremote procedure calls (RPCs) to enable programs executing on othercomputers in network environment 100 to perform I2P mapping functions.

Also included within the file system 280 is a set of checking processes283 that implement the novel verification and consistency checkingprocedures of the present invention. In accordance with a firstembodiment of the invention, the checking processes 283 include anoff-line file system verification procedure, described further below,that may be executed by an administrator. In a second embodiment of thepresent invention, the checking processes 283 may comprise an on-lineverification procedure that modifies function calls within the storageoperating system that load inodes (LoadInode( ) 285) and buffer trees(LoadBuffer( ) 286) so that before each inode or buffer tree is returnedto a process that called the loading function, a check is performed ofthe inode and related buffer trees. When a process executing within thestorage operating system calls either the LoadInode( ) 285 orLoadBuffer( ) 286 functions, the modified function suspends the returnof the requested object until a check is performed. The modifiedfunction loads the requested inode or buffer tree and determines if itis associated with a data container, e.g., a file or a directory. If therequested inode is a regular file inode, then the checking procedureverifies associated buffer trees of the inode. If the selected inode isa directory inode, then the checking procedure performs a directorycheck of the selected inode. Both the file and directory checks verifythat the I2P information associated with the data container is correct.Additionally, in the second embodiment relating to an on-lineverification procedure, a background process is initiated thatsequentially loads inodes. This background process ensures that allinodes of the file system are checked, even if another process orapplication does not request a particular inode.

It should be noted that the software “path” through the storageoperating system layers described above needed to perform data storageaccess for the client request received at the storage system mayalternatively be implemented in hardware. That is, in an alternateembodiment of the invention, a storage access request data path may beimplemented as logic circuitry embodied within a field programmable gatearray (FPGA) or an application specific integrated circuit (ASIC). Thistype of hardware implementation increases the performance of the storageservice provided by storage system 120 in response to a request issuedby client 110. Moreover, in another alternate embodiment of theinvention, the processing elements of adapters 126, 128 may beconfigured to offload some or all of the packet processing and storageaccess operations, respectively, from processor 122, to thereby increasethe performance of the storage service provided by the system. It isexpressly contemplated that the various processes, architectures andprocedures described herein can be implemented in hardware, firmware orsoftware.

As used herein, the term “storage operating system” generally refers tothe computer-executable code operable to perform a storage function in astorage system, e.g., that manages data access and may implement filesystem semantics. In this sense, the ONTAP software is an example ofsuch a storage operating system implemented as a microkernel andincluding the file system module to implement the write anywhere filesystem semantics and manage data access. The storage operating systemcan also be implemented as an application program operating over ageneral-purpose operating system, such as UNIX® or Windows XP®, or as ageneral-purpose operating system with configurable functionality, whichis configured for storage applications as described herein.

In addition, it will be understood to those skilled in the art that theinventive technique described herein may apply to any type ofspecial-purpose (e.g., file server, filer or storage appliance) orgeneral-purpose computer, including a standalone computer or portionthereof, embodied as or including a storage system 120. An example of astorage appliance that may be advantageously used with the presentinvention is described in U.S. patent application Ser. No. 10/215,917titled, MULTI-PROTOCOL STORAGE APPLIANCE THAT PROVIDES INTEGRATEDSUPPORT FOR FILE AND BLOCK ACCESS PROTOCOLS, filed on Aug. 9, 2002, nowissued as U.S. Pat. No. 7,873,700 on Jan. 18, 2011. Moreover, theteachings of this invention can be adapted to a variety of storagesystem architectures including, but not limited to, a network-attachedstorage environment, a storage area network and disk assemblydirectly-attached to a client or host computer. The term “storagesystem” should therefore be taken broadly to include such arrangementsin addition to any subsystems configured to perform a storage functionand associated with other equipment or systems.

C. Volume Structure

The file system, such as the write-anywhere file system, maintainsinformation about the geometry of the underlying physical disks (e.g.,the number of blocks in each disk) in the storage system. The RAIDsystem provides the disk geometry information to the file system for usewhen creating and maintaining the vbn-to-disk,dbn mappings used toperform write allocation operations. The file system maintains blockallocation data structures, such as an active map, a space map, asummary map and snapshot maps. These mapping data structures describewhich blocks are currently in use and which are available for use andare used by a write allocator 282 of the file system 280 as existinginfrastructure for the logical volume.

Specifically, the snapshot map denotes a bitmap file describing whichblocks are used by a snapshot. The write-anywhere file system (such asthe WAFL file system) has the capability to generate a snapshot of itsactive file system. An “active file system” is a file system to whichdata can be both written and read or, more generally, an active storethat responds to both read and write I/O operations. It should be notedthat “snapshot” is a trademark of Network Appliance, Inc. and is usedfor purposes of this patent to designate a persistent consistency point(CP) image. A persistent consistency point image (PCPI) is a spaceconservative, point-in-time, read-only image of data accessible by namethat provides a consistent image of that data (such as a storage system)at some previous time. More particularly, a PCPI is a point-in-timerepresentation of a storage element, such as an active file system, fileor database, stored on a storage device (e.g., on disk) or otherpersistent memory and having a name or other identifier thatdistinguishes it from other PCPIs taken at other points in time. A PCPIcan also include other information (metadata) about the active filesystem at the particular point in time for which the image is taken. Theterms “PCPI” and “snapshot” may be used interchangeably through out thispatent without derogation of Network Appliance's trademark rights.

The write-anywhere file system supports (maintains) multiple PCPIs thatare generally created on a regular schedule. Each PCPI refers to a copyof the file system that diverges from the active file system over timeas the active file system is modified. Each PCPI is a restorable versionof the storage element (e.g., the active file system) created at apredetermined point in time and, as noted, is “read-only” accessible and“space-conservative”. Space conservative denotes that common parts ofthe storage element in multiple snapshots share the same file systemblocks. Only the differences among these various PCPIs require extrastorage blocks. The multiple PCPIs of a storage element are notindependent copies, each consuming disk space; therefore, creation of aPCPI on the file system is instantaneous, since no entity data needs tobe copied. Read-only accessibility denotes that a PCPI cannot bemodified because it is closely coupled to a single writable image in theactive file system. The closely coupled association between a file inthe active file system and the same file in a PCPI obviates the use ofmultiple “same” files. In the example of a WAFL file system, PCPIs aredescribed in TR3002 File System Design for a NFS File Server Applianceby David Hitz et al., published by Network Appliance, Inc. and in U.S.Pat. No. 5,819,292 entitled METHOD FOR MAINTAINING CONSISTENT STATES OFA FILE SYSTEM AND FOR CREATING USER-ACCESSIBLE READ-ONLY COPIES OF AFILE SYSTEM, by David Hitz et al., each of which is hereby incorporatedby reference as though full set forth herein.

The active map denotes a bitmap file describing which blocks are used bythe active file system. As previously described, a PCPI may containmetadata describing the file system as it existed at the point in timethat the image was taken. In particular, a PCPI captures the active mapas it existed at the time of PCPI creation; this file is also known asthe snapshot map for the PCPI. Note that a snapshot map denotes a bitmapfile describing which blocks are used by a PCPI. The summary map denotesa file that is an inclusive logical OR bitmap of all snapshot maps. Byexamining the active and summary maps, the file system can determinewhether a block is in use by either the active file system or any PCPI.The space map denotes a file including an array of numbers thatdescribes the number of storage blocks used in a block allocation area.In other words, the space map is essentially a logical OR bitmap betweenthe active and summary maps to provide a condensed version of available“free block” areas within the vbn space. Examples of PCPI and blockallocation data structures, such as the active map, space map andsummary map, are described in U.S. Pat. No. 7,454,445, titled WRITEALLOCATION BASED ON STORAGE SYSTEM MAP AND SNAPSHOT, by Blake Lewis etal. and issued on Nov. 18, 2008, which is hereby incorporated byreference.

FIG. 3 is a schematic block diagram of an exemplary on-disk storagestructure 300 of a volume of a storage system. As noted, a volume istypically associated with a file system and comprises data blocksorganized within a vbn space. Each volume has a volinfo block that ispreferably stored at a fixed location within, e.g., a RAID group. Avolinfo block 302 is the root of the volume. The volinfo block containspointers to one or more fsinfo blocks 305A, B, C. Fsinfo block 305A isassociated with the active file system, while fsinfo blocks 305B, C maybe associated with PCPIs of the volume 300. An example of PCPIsassociated with a volinfo block 302 is described in U.S. Pat. No.7,313,720, issued on Dec. 25, 2007, entitled TECHNIQUE FOR INCREASINGTHE NUMBER OF PERSISTENT CONSISTENCY POINT IMAGES IN A FILE SYSTEM, byEmily Eng, et al.

The fsinfo block 305A includes a variety of metadata that describes thestate of the file system. Fsinfo block 305A contains a set of volumeoptions 307 including whether I2P mapping is active for the volume 300.In the illustrative embodiment, I2P mapping may be activated/deactivatedon a per volume basis. An administrator may activate the I2P mappingusing a command line interface (CLI) command implemented by the UI 275of the storage operating system 200. An example of such a CLI command isthe following volume command:

-   -   vol options <volume name> i2p [on|off]        where vol is the name of the command and options denotes that        the administrator desires to modify one of the volume options.        The volume is identified in the <volume name> field. The i2p        setting specifies whether the I2P mapping option is to be        activated (on) or deactivated (off). In an illustrative        embodiment, the volume may default to activating the I2P        mapping. Illustratively, the storage operating system 200        includes a programmatic remote procedure call (RPC) interface        that provides the same functionality as that available via CLI        commands embodied within the UI 275.

The fsinfo block 305A also contains an inode for an inode file 310. Allinodes of the write-anywhere file system are organized into the inodefile 311. Like any other file, the inode of the inode file is the rootof the buffer tree that describes the locations of blocks of the file.As such, the inode of the inode file may directly reference (point to)data blocks 307 of the inode file 311 or may reference indirect blocks306 of the inode file 311 that, in turn, reference data blocks of theinode file. In this example, the inode for the inode file 310 includesan exemplary buffer tree comprising a plurality of inode file indirectblocks 306 that, in turn, point to inode file data blocks 307. Withineach data block of the inode file are inodes 400, each of which servesas the root of a file. Among the inodes of the inode file 310 are inodesfor special metadata files, such as an active map 315, a summary map320, a space map 325, a root directory 500 and a metadata directory 345.All user files in the file system are organized under the root directory500, while various metadata files associated with the file system arestored under the metadata directory 345. Illustratively, the alternatename file 350 is located in the hidden metadata directory 345. Thealternate name file 350 is utilized to store I2P mapping informationassociated with alternate names of an inode and is illustrativelyimplemented as a B+ tree to enable fast searches.

The inode file may further include inodes that reference a plurality ofPCPIs 330, 335. These PCPI inodes are the root level inodes of PCPIs ofthe active file system. Each volume has special reserved inode numberswithin its vbn space. In certain illustrative embodiments, a pluralityof those inode numbers (e.g., 31) is reserved for PCPIs. When a PCPI ofthe active file system is generated, a copy of the inode for the inodefile is also generated (hereinafter the “snapshot root”) and assignedone of the reserved PCPI inode numbers. Thus, to access a PCPI at aparticular point in time, the storage operating system accesses theappropriate PCPI root of the PCPI. In other illustrative embodiments,only the PCPI root inodes are utilized.

D. Inode Structure

In the illustrative embodiment, a data container, such as a file, isrepresented in the write-anywhere file system as an inode data structureadapted for storage on the disks 130. FIG. 4 is a schematic blockdiagram of an inode 400, which illustratively includes a metadatasection 410 and a data section 450. The information stored in themetadata section 410 of each inode 400 describes the data container and,as such, includes the type (e.g., regular, directory, virtual disk) 412of data container, the size 414 of the data container, time stamps(e.g., access and/or modification) 416 for the data container,ownership, i.e., user identifier (UID 418) and group ID (GID 420), ofthe data container, a link count field 421 and a novel primary name datastructure 422. The link count field 421 tracks the number of names (and,implicitly, the number of hard links) associated with the inode. Forexample, a link count of one signifies that there are no hard links tothe data container and that the only name associated with the inode isthe primary name.

The primary name data structure 422 illustratively includes a parentdirectory inode field 424, a parent directory cookie field 426 and, inalternative embodiments, additional fields 428. The parent directoryinode field 424 contains an inode value that is associated with theparent directory of the data container. Thus, if the data container is afile bar located in the foo directory (i.e., /foo/bar) then the parentdirectory inode field contains the inode number of the foo directory.The parent directory cookie field 426 illustratively contains amulti-bit value that identifies a directory block and entry within thedirectory block of the directory identified by the parent directoryinode field 424.

The contents of the data section 450 of each inode may be interpreteddifferently depending upon the type of data container (inode) definedwithin the type field 412. For example, the data section 450 of adirectory inode contains metadata controlled by the file system, whereasthe data section of a file inode contains file system data. In thislatter case, the data section 450 includes a representation of the dataassociated with the file.

Specifically, the data section 450 of a regular on-disk inode mayinclude file system data or pointers, the latter referencing 4 KB datablocks on disk used to store the file system data. Each pointer ispreferably a logical vbn to facilitate efficiency among the file systemand the RAID system 240 when accessing the data on disks. Given therestricted size (e.g., 192 bytes) of the inode, file system data havinga size that is less than or equal to 64 bytes is represented, in itsentirety, within the data section of that inode. However, if the filesystem data is greater than 64 bytes but less than or equal to 64 KB,then the data section of the inode (e.g., a first level inode) comprisesup to 16 pointers, each of which references a 4 KB block of data on thedisk.

Moreover, if the size of the data is greater than 64 KB but less than orequal to 64 megabytes (MB), then each pointer in the data section 450 ofthe inode (e.g., a second level inode) references an indirect block(e.g., a first level block) that illustratively contains 1024 pointers,each of which references a 4 KB data block on disk. For file system datahaving a size greater than 64 MB, each pointer in the data section 450of the inode (e.g., a third level inode) references a double-indirectblock (e.g., a second level block) that contains 1024 pointers, eachreferencing an indirect (e.g., a first level) block. The indirect block,in turn, that contains 1024 pointers, each of which references a 4 KBdata block on disk. When accessing a file, each block of the file may beloaded from disk 130 into the buffer cache 170.

When an on-disk inode (or block) is loaded from disk 130 into buffercache 170, its corresponding in-core structure embeds the on-diskstructure. For example, the dotted line surrounding the inode 400indicates the in-core representation of the on-disk inode structure. Thein-core structure is a block of memory that stores the on-disk structureplus additional information needed to manage data in the memory (but noton disk). The additional information may include, e.g., a “dirty” bit460. After data in the inode (or block) is updated/modified asinstructed by, e.g., a write operation, the modified data is marked“dirty” using the dirty bit 460 so that the inode (block) can besubsequently “flushed” (stored) to disk. The in-core and on-disk formatstructures of the WAFL file system, including the inodes and inode file,are disclosed and described in the previously incorporated U.S. Pat. No.5,819,292 titled METHOD FOR MAINTAINING CONSISTENT STATES OF A FILESYSTEM AND FOR CREATING USER-ACCESSIBLE READ-ONLY COPIES OF A FILESYSTEM by David Hitz et al., issued on Oct. 6, 1998.

FIG. 5 is a schematic block diagram of an exemplary root directorybuffer tree 500 in accordance with an embodiment of the presentinvention. The directory buffer tree 500 contains a directory inode 505at its root. Depending on the size of the directory, there may be one ormore levels of indirect blocks 507 between the directory inode 505 andthe data blocks 510 of the directory. Each data block 510 comprises oneor more directory entries 515 A,B. In accordance with the illustrativeembodiment of the present invention, the parent directory cookie value426 uniquely identifies a particular directory entry within thedirectory identified by the parent directory inode field 424. That is,the inode identified by the parent directory inode field 424 identifiesa directory inode 505. The parent directory cookie value 426 identifiesa particular level 0 data block 510 of the directory and a particulardirectory entry 515 within that level 0 data block 510.

E. I2P Mapping Operations

As described in the above-incorporated U.S. Pat. No. 7,739,318, the I2Pfunctions 284 of the storage operating system 200 operate in conjunctionwith the file system 280 to permit processes to read and/or write I2Pinformation from either a primary name data structure within an inode orfrom an alternate name file. Such reading/writing operations, describedfurther below, may be utilized by the various checking processes of thepresent invention when determining whether the I2P information isconsistent or when repairing the I2P information during the course ofthe verification procedure. In accordance with the illustrativeembodiment of the present invention, any reading/writing techniques forobtaining/setting the I2P information may be utilized. As such, theseprocedures should be taken as exemplary only.

FIG. 6 is a flowchart detailing the steps of a procedure 600 forcreating a new name in a directory in accordance with an embodiment ofthe present invention. Procedure 600 is illustratively performed by thefile system and associated I2P functions when a data container is firstcreated and/or a new hard link is generated to a particular datacontainer. The procedure 600 begins in step 605 and continues to step610 where the file system receives an operation to create a new name ina particular directory. As noted above, the operation may be a createfile operation or a create hard link operation. In response, the filesystem creates the new name in step 615 using conventional file systemoperations. In step 620, the file system, in conjunction with the I2Pfunctions 284, determine whether the new name is the primary name forthe data container. If, for example, the operation is a create fileoperation, the new name is the primary name because the data containeris associated with no other name. However, if the operation is a createhard link operation, then the data container already has a primary namereflecting the name of the data container originally created. If the newname is the primary name, the procedure branches to step 625 where thefile system and I2P functions load the appropriate fields within theprimary name data structure of the inode. The procedure then completesin step 640. However, if in step 620, a determination is made that thenew name is not the primary name, then the procedure continues to step630 where the file system and I2P functions create a new entry in thealternate name file. As noted above, this entry is illustratively storedas a triplet of the inode, the parent directory inode and the parentdirectory cookie value. The procedure then completes in step 640.

FIG. 7 is a flowchart detailing the steps of a procedure 700 forretrieving I2P information in accordance with an embodiment of thepresent invention. This procedure may be invoked by an administrator oruser entering a command to retrieve the I2P information in response to,e.g., a message reporting an error condition with respect to aparticular inode number. An exemplary CLI command for retrieving I2Pmapping information, which may be implemented by the UI 275, is:

-   -   inodepath -v <volume> [-a] [-s<PCPIname>] <inodenumber>        where the -v option identifies the volume name identified in the        <volume> field in which the inode number identified in the        <inodenumber> field is located. Illustratively, the -a option        causes the command to print all of the names associated with the        inode, i.e., the primary name and all alternate names associated        with the inode. In an exemplary embodiment the program defaults        to only displaying the primary name. The -s option causes the        program to display the name(s) associated with the inode number        <inodenumber> located within the PCPI having the name        <PCPIname>. Thus, the program may display names associated with        previous point-in-time images of the file system. In the        illustrative embodiment the CLI command utilizes the I2P        functions 284 of the storage operating system 200 to retrieve        and display the information to the administrator.

The procedure 700 begins in step 705 and continues to step 710 where thefile system and I2P functions retrieve (read) the primary name datastructure from the inode. In step 715, the file system and I2P functionsdetermine whether the primary name data structure contains a zero value.Illustratively, a zero value within the primary name data structuresignifies that the file system has not yet identified the appropriateI2P mapping information for this inode. This may be because an initialscan, described further below, has not yet reached this particular inodeor may be due to corruption of the information which has resulted in thefile system clearing the I2P information to prevent incorrect resultsbeing returned. If the primary name data structure within the inodecontains a zero value, the procedure branches to step 720 signifyingthat the I2P mapping information is not set before completing in step740. Illustratively, a caller or program invoking procedure 700 willreturn to the user information signifying that the I2P mappinginformation is not available. In alternate embodiments, if the primaryname data structure is zero, then the file system invokes the scanner,described further below, to generate the appropriate information. Insuch alternative embodiments the scanner, which is part of the I2Pfunctions 284, generates the appropriate primary name data structurecontents before reinitiating procedure 700.

If, in step 715, the value is not zero then the procedure continues tostep 717 where a determination is made whether the option, e.g., -a, hasbeen selected to display alternate names. If the alternate names optionhas not been set, the procedure branches to step 735 and returns theprimary name before completing in step 740.

However, if in step 717 it is determined that the administrator desiresto display alternate names, the procedure continues to step 725 where adetermination is made as to whether the alternate name file containsentries associated with this inode. If the alternate names file does notcontain any associated entries, then the data container only has aprimary name, which is returned in step 735 before the procedurecompletes in step 740. The primary name is determined by examining thedirectory entry in the appropriate directory that is identified by thecookie value within the primary name data structure. However, if in step725 there are alternate names identified, then the file system returnsthe primary name and the alternate name(s) in step 730 before completingin step 740. The alternate name(s) are identified in a similar manner tothe primary name, i.e., the directory is identified by the parentdirectory inode and a specific entry within the directory is identifiedby the cookie value.

FIG. 8 is a flowchart detailing the steps of a procedure 800 fordeleting a name in accordance with an embodiment of the presentinvention. The procedure 800 begins in step 805 and continues to step810 where an operation to delete a name is received by the file system.The file system, in conjunction with I2P functions 284, performprocedure 800 to remove the name and to ensure that I2P mappinginformation remains up to date. A determination is made in step 815whether the name to be deleted is the primary name associated with theinode, i.e., the name stored in the primary name data structure withinthe inode. If the name to be deleted is the primary name, the procedurebranches to step 820 where the file system and I2P functions remove theappropriate directory entry and update the link count of the inode.

Once the directory entry has been removed and the link count updated,the procedure determines, in step 821, whether the link count is greaterthan zero for the inode. If the link count is not greater than zero,then the procedure branches to step 835 and completes. An inode willhave a link count when the one and only name associated with it isremoved, thereby indicating that the data container associated with theinode may be removed from the file system.

In step 825, an alternate name of the data container is “promoted” tothe primary name. Illustratively, the first alternate name stored in thealternate name file is selected and stored within the primary name datastructure of the inode as the new primary name. Once the newly promotedprimary name has been stored, the file system and I2P functions removethe promoted alternate name from the alternate name file in step 830before the procedure completes in step 835. However, if in step 815, itis determined that the name to be deleted is not the primary name, theprocedure branches to step 840 where the name is removed from thealternate name file. This may be accomplished using conventional B+ treeremoval operations. In alternate embodiments, where the alternate namefile is not implemented as a B+ tree, appropriate conventional entryremoval operations are utilized. In step 845, the appropriate directoryentry is removed and the link count of the inode is updated before theprocedure completes in step 835.

F. File System and I2P Verification

The present invention provides a system and method for verifying andrestoring the consistency of inode to pathname mappings from a datacontainer to its parent directory within a file system of a storagesystem. In a first embodiment, an off-line volume verification tool ismodified to, inter alia, verify the consistency of I2P informationwithin the file system. Any primary name data structures that areidentified as inconsistent are repaired so that each data structurecontains the appropriate information representative of the primary namefor the data container such as a file. The alternate name file isverified and if inconsistencies are noted therein, the alternate namefile is deleted and an I2P name mapping scanner is invoked toreconstruct the alternate name file.

In a second embodiment of the invention, an on-line file systemverification tool is modified to verify the consistency of the I2Pinformation within the file system. The on-line verification toolillustratively modifies function calls e.g., (LoadInode( )) and buffertrees (LoadBuffer( )) within the storage operating system that loadinodes and contents of buffer trees. Before an inode or buffer tree isreturned to a process that called the loading function, the verificationtool performs a check on the inode and related buffer trees.Illustratively, this check includes, inter alia, verifying and repairingthe consistency of the I2P information associated with the inode. In thesecond illustrative embodiment, a background process is created thatsequentially loads inodes so that all inodes of the file system arechecked, even if another process or application does not request aparticular inode.

Off-Line Verification

FIG. 9 is a flowchart detailing the steps of a procedure 900 forperforming an off-line verification of a file system including I2Pmapping information in accordance with an embodiment of the presentinvention. The procedure 900 begins in step 905 and continues to step910 where the appropriate checking program is initiated. This may beperformed by an administrator utilizing the user interface to invoke theoff-line verification procedure (which is illustratively part ofchecking processes 283) or may be caused by the happening of apredetermined event, such as an error condition. Upon initiation, theverification procedure suspends client messages in step 915. Notably,any previously received client messages, such as data access operationsare processed; however, any later received messages are not processed.Depending on the protocol utilized to access the volume, an errormessage may be returned and/or a timeout may occur. Once client messageshave been suspended and any received messages processed, theverification procedure unmounts the volume in step 920. This may beperformed using conventional file system processes. Typically,unmounting the volume causes the file system to flush any in-memorycaches so that the volume is in a consistent state.

In step 922, the verification procedure selects an inode from the inodefile and, in step 925, verifies the buffer tree associated with theinode. In step 930, the verification procedure then verifies the I2Pmapping information for the primary name associated with the selectedinode. In step 935, the verification procedure determines whether thereare additional inodes to be verified. If so, the verification procedureloops back to step 922 and selects another inode. However, if there areno additional inodes to be scanned, the verification procedure continuesto step 940 where it verifies the alternate name file. Verification ofthe alternate name file includes, inter alia, ensuring that anappropriate entry appears in the alternate name file for each alternatename identified while scanning the inode file. Similarly, suchverification may include ensuring that there are no extraneous and/orduplicate entries within the alternate name file. In step 945, adetermination is made whether the alternate name file is fullyconsistent. If so, the verification procedure continues to step 950 andmounts the volume before resuming client messages in step 955. Theprocedure then completes in step 960.

However, if the alternate name file is not consistent, then theverification procedure branches to step 965 and removes the alternatename file. Once the alternate name file has been removed, theverification procedure then initiates a name mapping scanner toreconstruct the I2P alternate name file. Such a name mapping scanner isfurther described in the above-incorporated U.S. Pat. No. 7,739,318. Thename mapping scanner proceeds independently of the verificationprocedure to populate the alternate name file. The procedure continuesto step 950 where the verification procedure mounts the volume beforeresuming the processing of client messages in step 955. The procedurethen completes in step 960.

On-Line Verification

In a second embodiment of the present invention, an on-line check of thefile system modifies the LoadInode( ) and LoadBuffer( ) functions of thestorage operating system so that upon the retrieval of an inode and/orbuffer tree, a series of verification checks are performed. Theinitialization procedure 1000 of the illustrative on-line file systemchecking process is shown in FIG. 10. In step 1005, an administratorenters an on-line checking command via a command line interface (CLI) orvia a graphical user interface (GUI) or via any other input methodology.In alternate embodiments, the storage operating system can be configuredso that the file system check automatically initiates upon a set event,for example, a crash or other error condition. Upon entry of thechecking command, the file system suspends client messages in step 1010.Suspension of client messages means that the file system will acceptfile system commands including, for example, data write and/or readcommands. However, while the client messages are suspended, the filesystem will not act upon these commands. To the process or clientinitiating the file system command, it appears that there is a delay inthe execution of the command.

In step 1015, the volume to be checked is unmounted. In the illustrativeembodiment, the unmounting of a volume causes any in-core cachedinformation to be flushed to the physical disks of the volume, therebyplacing these disks in a consistent state. In step 1020, the checkingroutines are initialized. In the illustrative embodiment, the filesystem includes a function that retrieves an inode (LoadInode( ) 285)for further processing. To perform on-line checking, the checkingprocesses modify this LoadInode( ) 285 function to include a check ofthe file system structure, e.g., inode or directory, being accessed. Thechecking process first performs the check of the inode to be retrievedbefore returning the inode to the process that called the LoadInode( )function 285. The volume is then remounted as described in procedure1100. Once the volume is remounted, the file system resumes clientmessages in step 1025 such that client messages which have either beensuspended or which are later received by the file system layer areprocessed using the modified LoadInode( ) function 285. Thus, anyrequest for an inode will first check that inode and associated buffertrees before returning the inode to the calling process. The procedure1000 then completes in step 1030.

FIG. 11 is a flowchart linking a procedure 1100 performed by the filesystem when mounting a volume in accordance with a second embodiment ofthe present invention. The volinfo and fsinfo blocks are first loaded instep 1105. The volinfo and fsinfo blocks, as described above, containnumerous metadata relating to the file system. In step 1110, an inodefile is selected. Typically, the inode file associated with the fsinfois selected. However, in certain configurations, alternate inode filesare loaded. In step 1115, the active map is loaded. The active map is adata structure that is utilized by the file system to track which blocksare used by the active file system. It should be noted that during thisand other subsequent load operations, the modified LoadInode( ) function285 is utilized. Thus, during mounting of the volume by the file system,the various inodes and directories associated with the file system filesare verified. In step 1120, the summary map is loaded. The summary mapstores metadata and when determining which blocks are used by any PCPIsstored by the file system.

In step 1125, the space map is loaded. The space map is a map of thevarious blocks of the file system indicating which blocks are utilizedby the active file system and which are free to be allocated. Step 1130,the block type map is loaded. The block type map identifies the use of ablock. For example, a block could be used as a data holding block, or asa directory block. Next, the PCPI inodes are loaded in step 1135 and thesnap maps are loaded in step 1140. In step 1145, the quota trees areloaded. A quota tree (or qtree) is a subset of a volume that is definedby a directory. A quota specifies the maximum amount of storageresources available to a qtree. Thus, if it is desired to limit storagefor a project having many users, it is appropriate to specify a quota ona qtree instead of an actual security object. Multiple qtrees can becreated on a single volume, with each qtree having a different size (asdesired). However, the qtree can also be created without a limit(quota). A qtree is essentially a mini-volume with the property thatevery object within the qtree has a qtree ID in its inode. Thisinformation is scanned and identified by the file system.

As each of these file system metadata files is loaded using the modifiedLoadInode( ) function 285, each file also is checked in accordance withthe teachings of this invention. Thus, by the completion of a volumemount operation, the above-mentioned file system metadata files havebeen checked. Note that some files, such as the inode file, whichcontain a large quantity of data may be only selectively checked so asto reduce processing time and overhead. It should be noted that theabove-mentioned metadata files are illustrative and that in alternateembodiments of the present invention additional and/or differingmetadata files may be checked.

FIG. 12 is a flowchart illustrating a procedure 1200 performed by theverification processes when performing an on-line check in a filesystem. In step 1205, a process within the storage operating systemcalls the LoadInode( ) function 285. As the LoadInode ( ) function hasbeen modified, the traditional LoadInode( ) functionality has beensupplemented by the procedure described herein. The inode file blockrequested with the LoadInode( ) command is then retrieved (step 1210).The inode file block could be in-core if it has been recently utilized,or may be physically located on disk. If the inode file block is ondisk, then the file system retrieves the data block from disk by sendingthe appropriate commands to the RAID and disk driver layers of thestorage operating system. In step 1215, the return message to theprocess that called the LoadInode( ) function is suspended. Suspensionof the return message lasts for the duration of the check of thisparticular inode. Thus, to the process calling the LoadInode( ) command,it appears that a request has incurred some latency. This enableson-line checking of the file system with minimal disruption of service.Although requests for inodes are delayed while the inodes are checked,the file system, as a whole, remains on-line and available for use. By“on-line” it is meant that the file system is accessible by users forread and/or write functions.

In step 1220, the file system checking routine determines the type ofinode that has been requested. If the inode requested is a file inode,then the checking process performs an inode check as described inprocedure 1300. However, if the inode requested is a directory inode,then the checking process performs a directory check as described inprocedure 1400.

To check an inode, the buffer trees associated with the inode areverified in accordance with procedure 1300 shown in FIG. 13. Thisprocedure operates by traversing the various branches of the buffer treeand verifying certain key items. In step 1305, the inode check verifiesthat all pointers in the buffer tree are valid. If a pointer is directedto an invalid block, the pointer is cleared. In step 1310, the inodechecking process verifies that no cross-links exist within a buffertree. If a block has multiple pointers to it, the inode checking processclears all but the first pointer (step 1315). Thus, the first block topoint to a given block is retained with any other blocks having theirpointers removed. In step 1317 the I2P information for the inode isverified. This illustratively includes, e.g., verifying that the primaryname data structure is consistent with the file system. The I2Pinformation is verified by, for example, reading the primary name datastructure associated with the inode using, e.g., procedure 700. Theretrieved primary name is then compared to the file system to ensurethat it is consistent, i.e. both the file system and the primary namedata structure identify the same name for the data container. If the I2Pinformation is inconsistent, the process corrects the primary name datastructure. Finally, the inode is marked as being checked (step 1320).Such marking can be accomplished by modifying a tracking file, describedfurther below, or by modifying a bit within the inode's metadata.

FIG. 14 is a flowchart illustrating the procedure 1400 performed by theverification process when checking a directory. The checking processfollows the directory tree upwards to the root directory. For example,if the sub directory of the path “/dir1/dir2/sub” is being checked, thechecking process first moves to the dir2 directory and then to the dir1directory before finding the root directory. Traversal of the directorytree can be accomplished by, for example, accessing a special entry in adirectory that identifies the directory's parent directory. In oneembodiment, this special entry is denoted “..” (dot-dot) within adirectory.

After the directory tree has been traversed upwards as far as possible,the process determines if the directory is linked to the root directoryof the volume (step 1410). If the directory is not linked to the rootdirectory, the process determines if the directory is a specialdirectory that should not be linked to the root directory in step 1415.An example of such a special directory is a metadirectory storing filesystem metadata. Metadirectories are further described in U.S. Pat. No.7,386,546, issued on Jun. 10, 2008, entitled METADATA DIRECTORY FILESYSTEM, by Douglas Santry, et al. If the directory is not a specialcase, then the directory is linked to a lost and found directory (step1420) for later processing. The lost and found directory can be accessedby a user or administrator of the storage system to determine whatfurther actions should be taken with respect to these directories.

If the directory does link to the root directory or if the directory isa special case that does not need to link to the root directory, thechecking process then loads the file system objects that are one levelbeneath the directory (step 1425). These file system objects include,for example, subdirectories of the selected directory or files stored inthe selected directory. Additionally, each directory entry is loaded toobtain a list of names that are utilized to verify the alternate namefile.

Next, the checking process performs the above-described buffer treechecks of the buffer trees associated with the directory. In step 1430,the process verifies that all pointers within the buffer tree are valid.If there are invalid pointers, i.e. a pointer points to an invalid inodeor file data block, the pointer is cleared. In step 1435, the processchecks that no cross links exist within the buffer tree. If multipleblocks point to a given block, then all but the first pointer is removedin step 1440. Finally, in step 1445, the directory is marked has havingbeen checked. Such marking can be accomplished by the use of a trackingfile, described further below.

To ensure that all inodes of the file system are checked in a timelymanner, a background process (not shown) is initiated by the file systemchecking process. By “background process” it is meant generally aprocess executing at a low priority within the storage operating systemthat performs a given function with no user input. The procedureperformed by this background process is shown in FIG. 15. A counter (N)is initially set to a value of one (step 1505). The background processthen calls the LoadInode( ) function requesting the Nth inode, i.e.LoadInode(N). The LoadInode( ) function has been modified to incorporatechecking and as such, the requested inode is checked. Next, the counteris increased by one (step 1515). The background process determineswhether all inodes in the file system have been checked in step 1520 by,e.g., utilizing the file system tracking files, described below. If allinodes have been checked, the process then verifies the alternate namefile in step 1522. If an entry is missing, the process adds the entry.If an entry should not exist, i.e., there is no corresponding name inthe file system, the superfluous entry is removed. The checking processensures that the alternate name file is consistent with the file system.If the alternate name file is severely corrupted, the checking processmay remove the alternate name file and initiate an I2P scanner torepopulate the alternate name file.

In the illustrative embodiment, the file system checking process createsa file within the file system being checked. This file storesinformation relating to those inodes, buffer trees and directories thathave been checked by the file system process. By storing the statuswithin a file on the active file system, memory is saved. This file mayalso be utilized to store alternate names for later verification withthe alternate name file.

The foregoing description has been directed to specific embodiments ofthis invention. It will be apparent, however, that other variations andmodifications may be made to the described embodiments, with theattainment of some or all of their advantages. For instance, it isexpressly contemplated that the teachings of this invention can beimplemented as software, including a computer-readable medium havingprogram instructions executing on a computer, hardware, firmware, or acombination thereof. Accordingly this description is to be taken only byway of example and not to otherwise the scope of the invention.Therefore, it is the object of the appended claims to cover all suchvariations and modifications as come within the true spirit and scope ofthe invention.

What is claimed is:
 1. A method for verifying consistency of inode topathname information of a storage system, the method comprising:requesting, by a process executed by a processor of the storage system,an inode associated with a data container that is serviced by thestorage system, the processor further executing a file system;determining a type of the requested inode; in response to determiningthat the type of the requested inode is a file inode, performingverification by (i) comparing a first primary name maintained within aprimary name data structure of the file inode with a second primary namemaintained by the file system, and (ii) repairing the first primary namewithin the primary name data structure of the file inode to beconsistent with the second primary name maintained by the file systemwhen the first primary name and second primary name do not match; inresponse to determining that the type of the requested inode is adirectory inode, performing the verification by removing all invalidpointers within buffer trees associated with the directory inode andremoving all cross links within the buffer trees associated with thedirectory inode; and returning the requested inode to the process uponcompletion of the verification.
 2. The method of claim 1 furthercomprising: promoting at least one alternate name stored in an alternatename data container to the primary name data structure within therequested inode when the primary name has been deleted.
 3. The method ofclaim 2 further comprising: using a parent directory inode field and aparent directory cookie field associated with the primary name datastructure.
 4. The method of claim 1 further comprising: in response todetecting one or more inconsistencies in an alternate name datacontainer configured to maintain alternate names, deleting the alternatename data container; and invoking an inode-to-pathname scanner toreconstruct the alternate name data container.
 5. The method of claim 1further comprising: configuring an alternate name data container tostore alternate names as a file in a hidden directory of a volume of thestorage system.
 6. The method of claim 1 further comprising: receivingone or more access requests, via a network adaptor of the storagesystem, directed to the requested inode; in response to receiving theone or more access requests directed to the requested inode, suspendingthe one or more access requests; and unmounting a volume of the storagesystem, the volume associated with the requested inode.
 7. The method ofclaim 6 further comprising: mounting the volume after performing theverification; and resuming the one or more access requests directed tothe requested inode.
 8. The method of claim 1 further comprising:performing the verification using an off-line procedure.
 9. A systemconfigured to perform a verification check of a storage system,comprising: a processor of the storage system configured to execute aprocess to request an inode associated with a data container serviced bythe storage system executing a file system; a checking process forexecution by the processor configured to: determine a type of therequested inode, in response to determining that the type of therequested inode is a file inode, perform verification by (i) comparing afirst primary name maintained within a primary name data structure ofthe file inode with a second primary name maintained by the file system,and (ii) repairing the first primary name within the primary name datastructure of the file inode to be consistent with the second primaryname maintained by the file system when the first primary name andsecond primary name do not match, in response to determining that thetype of the requested inode is a directory inode, perform theverification by removing all invalid pointers within the buffer treesassociated with the directory inode and removing all cross links withinthe buffer trees associated with the directory inode; and a storageoperating system of the storage system for execution by the processorconfigured to return the requested inode to the process upon theverification.
 10. The system of claim 9 wherein the primary name datastructure comprises a parent directory inode field and a parentdirectory cookie field.
 11. The system of claim 9 wherein the checkingprocess is further configured to verify alternate names by removingduplicate or erroneous alternate names within an alternate name datastructure, and initiate a name mapping scanner to reconstruct thealternate name data structure.
 12. The system of claim 9 wherein analternate name data structure is stored in a hidden directory of thevolume of the storage system.
 13. The system of claim 9 wherein thestorage operating system is further configured to suspend one or moreclient messages directed to the data container, and further configuredto unmount a volume of the storage system, wherein the volume isassociated with the requested inode.
 14. The system of claim 13 whereinthe storage operating system is further configured to mount the volumeafter the verification, and further configured to resume the one or moreclient messages directed to the data container.
 15. The system of claim9 wherein the requested inode comprises a directory.
 16. The system ofclaim 9 wherein the requested inode comprises a file.
 17. The system ofclaim 9 wherein the checking process comprises an off-line procedure.18. A non-transitory computer readable media containing executableprogram instructions executed by a processor, comprising: programinstructions that request an inode associated with a data container thatis serviced by a storage system executing a file system; programinstructions that determine that a type of the requested inode is a fileinode or a directory inode; program instructions that performverification by (i) comparing a first primary name maintained within aprimary name data structure of the file inode with a second primary namemaintained by the file system, and (ii) repairing the first primary namewithin the primary name data structure of the file inode to beconsistent with the second primary name maintained by the file systemwhen the first primary name and second primary name do not match inresponse to determining the type of the requested inode is the fileinode; and program instructions that perform the verification byremoving all invalid pointers within buffer trees associated with thedirectory inode and removing all cross links within the buffer treesassociated with the directory inode in response to determining that thetype of the requested inode is a directory inode.
 19. An apparatus forperforming a verification check of a storage system, comprising: meansfor requesting an inode associated with a data container that isserviced by the storage system executing a file system; means fordetermining that a type of the requested inode is a file inode or adirectory inode; means for performing verification by (i) comparing afirst primary name maintained within a primary name data structure ofthe file inode with a second primary name maintained by the file system,and (ii) repairing the first primary name within the primary name datastructure of the file inode to be consistent with the second primaryname maintained by the file system when the first primary name andsecond primary name do not match in response to determining the type ofthe requested inode is a file inode; and means for perform theverification by removing all invalid pointers within buffer treesassociated with the directory inode and removing all cross links withinthe buffer trees associated with the directory inode in response todetermining that the type of the requested inode is a directory inode.